回顾·对话机器人在瓜子的实践

本文根据车好多NLP方向负责人王文斌老师在DataFun“AI+”Talk—— “Application of AI In Second Hand Market”中分享的《对话机器人在瓜子的实践》编辑整理而成。

今天主要分享以下几个方面，首先介绍下什么是对话机器人，然后讲一下技术选型的过程，设计了怎样的算法架构和系统架构，最后分享下线上的效果以及在瓜子中面临的一些挑战。

目前对话机器人很火，是有多方面原因的：第一，图灵在定义智能时就将对话机器人作为人工智能的一个标志；第二，深度学习技术越来越成熟，对话机器人在工业界已经达到一定水平；第三，对话机器人由于有智能客服的积累，有很多公司在做这方面的东西。上面是一个智能客服设计图，左边是接入渠道，登录进来，会提供一些客服产品，如机器人客服、人工在线客服、云呼叫中心，以及用户依据产品做一些自助服务。聊天过程中用户会将其数据留下来（反馈数据、对话数据、人工客服数据），利用这些数据就可以做分析，如客服数据可以做质检，用户数据可以做营销工作，与CRM接入打通。

接下来讲一下会什么要有对话机器人，开始瓜子目标就是提高效率，用机器替代人，达到缩减人力和培训成本、7*24小时在线服务、质量可控的目标。在发展的过程中概念慢慢升华到一个在线化的概念，就是数字化、数据化和智能化。数字化就是将用户和企业交互的数据都记录下来，将数据结构化，做成算法可用的数据叫数据化，有了数据化就可以用建模等一系列智能化手段做一些智能化提升。在线化做后可以做到整个沟通可追踪、提供可优化、差异化的服务以及精细化运营，最终推动企业在线化。

在线机器人是在线聊天的一部分，既是整个服务闭环的入口也是出口。用户可以在聊天中表达和解决相应的诉求，而搜索、推荐更像是一个被动的过程，IM是一个主动表达诉求的门户。

对话机器人的分类：开放式的有微软小冰、度秘；任务导向的有订机票、询问天气。从角色定位角度，如提供IM通道其实就是架构，只有有了骨架才能做相应的应用，算法在里面是一个关键的作用，后期其实更多的是偏产品化的东西。对话机器人技术是透明的，区别在于谁做的细节更完善。开发的角度就是完善三个视图，客户视图： 对话内容、对话框、对话框外推荐信息；客服视图：对话上下文、客户画像、背景信息、订单画像，管理者视图：控制台、知识库。

对话机器人经典流程：语音唤醒，告诉你要干嘛，唤醒之后经过语音识别转化为文本，这时候可以做语义理解（其中可能需要知识库交互），将语义理解的结果通过对话管理引擎拿到用户对应的话术，将对应的话术转化为文本，最后转化为语音输出。

说明下对话机器人的核心概念，如“帮我定一张明天上午10点从北京到上海的机票”，这句话的意图就是“订机票”。槽位就是如果要完全理解一句话并且能够够返回结果信息还需要什么属性，这句话槽位信息有：起飞时间 = 明天早上10点，起始地 = 北京，目的地 = 上海。

接下来讲一下技术选型，这是对话机器人选用技术调研的过程。对话机器人开始是基于关键词，然后就是模板技术，目前很多公司还在使用，优点是质量可控、准确率高，其缺点就是泛化能力比较弱。随着功能不断迭代，模板很大程度依赖于人工，不能自主提升自己的泛化能力。然后有了基于搜索的对话机器人，有很强的业务适应能力，其缺点就是准确率低。最近几年深度学习火起来后，利用深度学习替换原来的模型进行意图识别，意图识别相对传统方法准确率提升很大，但是缺点就是对数据质量要求较高。

模板可以部分自动生成，如果上线也需要应用方自己审核与补充，话术也需要应用方自己去配置。搜索技术更多的是先用意图识别做一个路由器的功能，然后路由到一些小的robot，每个robot做一类事情。深度学习与传统分类方法做的事情类似，也是在做多意图的意图分类，确定意图后会通过一对一或其他配置方式将其关联回答。

下面是一个模板算法，“泉州过户到厦门会不会很麻烦”，这个模板在前面没有出现过，就无法匹配，需要将模板提取出来，固化到知识库、模板库中。

对话机器人发展到后面越来越注重运营，有一个管理平台，就是知识库。固化知识，给运营提供管理入口。前面例子就是维护问题到模板以及模板到回答的映射关系，人工需要做很多审核以及一些校对的工作。而搜索方案，将query经过预处理打散成terms，进入搜索系统，如果按照原始结果会得到一个排序“泉州到厦门过户问题，泉州到厦门远吗，泉州到厦门怎么坐车，泉州到福州过户问题，泉州到厦门过户问题”，最后得出结果与查询一致，将最相近的query回答返回。而解决排序不正确的方法就是需要海量数据。

接下来讲一下深度学习的算法架构，深度学习应用很多，以对话机器人而言，基础技术如分词、词性、实体识别都可以用深度学习，数据好的话会比传统方法好。还有搜索架构中的相似度计算、用来排序的一些特征也可以用到深度学习的方法。我们是从整个结构来看就是一个深度学习的架构，这也是学术界研究的热点。

深度学习知识库我们解决就是意图与答案一对一的关系，回答对话术本身要求很严格，几乎是一个纯人工的过程，有很多人参与业务运营。如果是单轮就是一个多分类问题，更重要的是如何建立一种机制将问题积累过程与上线后模型的演进过程变得更加自动化、质量更可控。除了刚才它谈到的技术还有其他方法如生成模式，学术界较火，主要是应用于闲聊。我们最后选用深度学习模式，考虑的原因有以下几个方面，就是不再需要人去抽取大量的特征。

语义理解的流程，包括快速识别、模型识别、搜索识别、相似问题，在这个流程中应用了很多技术。我们采取的是一个漏斗方式，开始是快速识别（需要实时解决），在快速识别弄一个白名单用关键词或模版匹配立刻纠正，原则是必须准确率要高。90%的问题是依据模型框架，准确率也在90%以上，有了前面两步，后面是在补充召回的过程，通过搜索系统借助文本相似度的匹配将一部分数据召回，尽量让用户更多的问题被识别。

接下来介绍下多轮，我理解多轮是一个更偏工程的过程。里面更多的算法是在做槽位解析，需要做好三件事，第一个就是填槽，如果对话过程中槽位未补全，在下轮对话过程中引导用户补全槽位信息。再者就是场景管理，需要维护海量用户的聊天信息。第三点就是可配置，多轮最后面都是一个业务问题，开发一个可配置的界面，让运营自行配置其需要的对话。多轮的逻辑是在知识库里配置的，DM是和业务无关的，只需要按配置的解析结果执行即可。

按照上面设计还是会出现风险，常见的五个风险有：任何算法的选择都只是满足当前的需求，数据是历史数据，算法是当前反馈，业务演化过程不可知； 模型互搏，各种模型都要去做A/BTest确定哪种好那种坏，之前更多的判断是从原理上判断；意图爆炸，目前知识库是基于意图回答一对一关系，业务相对收敛，但是未来发展速度可能导致意图不可收敛； 主观标准的反复，很多过程都由人工参与，每个人评判标准不一；模型更新滞后于业务发展，技术发展较快。解决方案就是永远保持主动，提前应对。

系统架构：前端有一个对话框和消息服务器，类似于IM基本架构，消息服务器会将消息路由到对话管理模块（中控）。用户聊天文本会在中控识别意图和槽位，通过意图在知识库中获取对应的话术。知识库有一个控制台，与外部交互的界面，对话管理也会访问后端云服务，比如通过ip地址获取其属于哪个城市，除此外还有语义理解、CRM服务等。

线上效果，左边是一个单轮对话能力，无论问如何贷款都能准确识别，右边是一个动态API，类似于知识图谱想要完成的工作。

在瓜子遇到的挑战：首先是数据，不管做什么都需要数据。运营，这方面主要是对话机器人自学习的能力，如何设置一些机制使运营能够满足当前业务效果，跟上业务发展速度。最后是产品化，如何将产品细节做得足够好。

举例：第一个就是数据来源，以一定规则构造数据，或利用非结构化数据通过迁移学习训练embedding向量，将向量作为意图识别的原始输入，或模型产生数据反哺模型，不断迭代。第二个就是话术的确认流程，编辑发起修改，业务反馈，编辑确认，审核，法务，上线，这是一个理想的模式。人与人之间的平衡： 回答的标准，新增意图的标准，产品和算法的平衡： 意图预判、suggest、相似问题、下一个问题，业务和技术的平衡：卡片消息，就是在线化，后台服务如何让用户利用起来。

用户从不同的业务入口进来看到的问题列表是不同的，从不同业务阶段进来看到的问题列表也是不一样的。后续希望做到不仅根据业务状态还要基于历史数据做一些推荐。对话机器人可以做很多事情，如目前我们正在做的精准营销，通过多轮对话完善用户诉求，给出更加精准的推荐。

下面更多是一种理念，打通CRM等内部系统，可以利用数据做商业智能，覆盖售前、售中、售后所有场景，用户沟通可追踪可优化，精准营销，从客服转化为专家顾问，实现用户服务在线化和企业在线化，最终实现整个企业的智能化。

作者介绍：

王文斌，车好多NLP方向负责人。硕士毕业于北京大学，曾就职于美团、百度等公司，在编译器、浏览器、IM、大数据等复杂系统研发上有实践经验，并在搜索推荐、知识问答、数据挖掘、机器学习、NLP等算法方向有丰富的积累。加入车好多后发起了智能IM项目，实现了对话机器人的成功落地。

团队介绍：

瓜子NLP团队，以chatbot等产品，增加人效，提高服务质量，让瓜子逐步加大服务线上化的比例。团队承载瓜子服务线上化的重任，是未来瓜子发展的重要基础能力之一。

——END——

内推信息：

在看NLP算法工程师、数据挖掘工程师机会的小伙伴，欢迎加入文斌老师的团队，内推邮箱：[e-mail]。

再看看其他文章？

喜欢我们就分享一下吧~~